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Beschreibung 

Rechner- und/oder Sof tware-Architektur unter Verwendung von 
Micro-Kernel- und Multi-Tier-Konzept mit Komponententechnik 

Die Erfindung betrifft die Rechnerarchitektur fur den 
Ablauf von Software Applikat ionen und vorzugsweise ein 
Verfahren und ein System zur Steuerung und/oder Organisation 
eines Applikationsprozesses in einem verteilten System mit 
mindestens einem Client und mindestens einem Server, bei dem 
das System nach einem sogenannten Multi-Tier-Modell organi- 
siert ist und zumindest eine erste Prasentationsschicht, eine 
zweite Schicht und eine dritte Datenschicht umfalit. 

Da die Entwicklung von Software grundsat zlich teuer und 
schnellen Anderungen unterworfen ist, sollte eine Architektur 
gewahlt werden, die folgende Punkte berucksichtigt : 

- eine Modularisierung in Form von kleinen Software Komponen- 
ten unterstiitzt, 

- einfache Kommunikation zwischen den Komponenten erlaubt, 

- Ausrichtung an Industriestandards mit dem Ziel Drittsoft- 
ware mit verwenden zu konnen, 

- Skalierung iiber eine variable Anzahl von Rechnern nur mit 
Administrationsauf wand und 

- Anpassbarkeit an spezifische Kundenprof ile nur mit Admi- 
nistrationsauf wand ist moglich, 

- Sicherstellung der Funktion und Benut zbarkeit alten Codes 
und 

- Unterstut zung eines leistungsf ahigen Patching-Konzepts . 

Deshalb sind bisher im Stand der Technik Architekturen vorge- 
schlagen worden, die diese Punkte moglichst weitgehend be- 
riicksichtigen . 

Als ein alterer Ansatz ist hier die reine Client Server 
Struktur zu nennen. Die Darstellungsschicht stellt hier den 
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Datenbank Client und die Datenschicht das Datenbank Manage- 
ment System (DBMS) dar. Hier fuhrte die Trennung (Modulari- 
sierung) von Grafik und Datenverarbeitung dazu, dass in der 
Darstellungsebene mit SQL Statements gearbeitet wird und in 
5 der Datenebene mit Hilfe von Stored Procedures und Pass 
Through Techniken problemspezif ischer Code implementiert 
werden muss. 

Obwohl dies sehr schnelle Losungen erlaubt, hat man bei 
10 Software Anderungen viele verschiedene Orte in den Programm 
Sourcen, an denen die Konsequenzen der Anderung (sogenannte 
side effects) beachtet werden mussen. Dies erweist sich als 
sehr f ehleranf allig. 

15 Als unvorteilhaf t erweist es sich in der Praxis namlich, dali 
die jeweils miteinander kommunizierenden Prozesse von Client 
einerseits und Server andererseits sehr viel voneinander 
wissen mussen, so dali ein problemloser Datentransf er ermog- 
licht wird. Dies fiihrt nachteiligerweise wiederum zu einer 

20 hohen Anzahl von expliziten Eingriffen bei Anderungen oder 
Anpassungen etwa hinsichtlich der Giiltigkeit oder Zugriffs- 
rechten . 




Die asynchrone Ruckantwort fur eine Datenbank Anfrage kann 
25 iiber in diesem Modell nach dem Stand der Technik liber eine 
Callback Schnittstelle realisiert werden. Hierbei wird iiber 
den client-seitigen Aufruf dem DBMS der Aufrufpunkt der 
Funktion mitgegeben, die dann die Ergebnisse erhalt . Vorher 
muss aber das DBMS dem Aufrufer Inf ormationen iiber den Typ 
30 der erwarteten Callback Schnittstelle liefern. Als nachteilig 
erweist es sich jedoch, dass das Einrichten einer Callback 
Funktion einen erheblichen Aufwand darstellt, der dann an- 
wachst, falls es sich urn eine verteilte Applikation handelt 
und Verweise bzw. Pointer noch iiber Rechnergrenzen hinweg 
35 verwaltet werden mussen. 



i* 
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Alle diese Probleme fuhrten in Stand der Technik zu einem 
weiteren Ansatz, dem Multi Tier Ansatz, der es erlaubt auf 
Callbacks zu verzichten . 

5 Eine Multi Tier Architektur enthalt mindestens 3 Schichten 
(hier Tiers genannt) : 

- eine erste Schicht,. die Darstellungs- bzw. Prasentations- 
schicht mit den Graf ikkomponenten, 

- eine zweite, mittlere Schicht (auch Middle Tier genannt) 
10 mit der Business Logik und 

- eine dritte Datenschicht mit den Datenbanken. 

) Die drei Schichten kommunizieren uber Schnittstellen, indem 
sie Aufrufe von "oben nach unten" - also von der ersten bis 
15 zur dritten Schicht - bearbeiten. Die jeweiligen Ruckantwor- 
ten werden nach Bearbeitung wieder als sogenannte Return 
Values von unten nach oben weitergereicht . 

Als problematisch hat es sich hier erwiesen, daft der aktive 
20 Teil des Prozesses der aufrufenden Komponente (ein sogenann- 
ter Thread) der ersten Schicht so lange blockiert bleibt, bis 
das Ergebnis aus der dritten Schicht, namlich meistens das 
Ergebnis einer Datenbankabf rage, vorliegt. 

25 Hier werden alle Prozesse, die die dritte Schicht betreffen, 
namlich Datenbank spezifischer Code, in die mittlere Schicht 
herausgezogen und somit eine Entkopplung von dem DBMS zu 
erreichen . 

DerNachteil ist, dass Anderungen beim Zugriff auf die Daten- 
30 bank, nun in mehreren Komponenten vorgenommen werden miissen. 

Ein weiterer Ansatz fur eine Betriebssystem Architektur ist 
das theoretischen Arbeiten an der Carnegie Mellon University 
entstammende MACH Modell. Dieses Modell basiert auf einem 
35 Micro Kernel Ansatz und erfordert eine konsequente Client 
Server Struktur. Dabei enthalt der Kernel bzw. Kern nur 
Clients, wahrend die Peripherie die vollen Dienstleistungen, 
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also die Server umfailt. Benotigt ein Server die Dienstleis- 
tung eines anderen Servers, so sendet er eine Anfrage durch 
den Micro Kernel. 

Dieses Konzept wird fur Betriebssysteme und deren Prozesse, 
wie beispielsweise die Interprozess-Kommunikation oder 
Dateiverwaltungs-Strategien eingesetzt. In Hinblick auf die 
Organisation von Applikationsprozessen unterstiitzt es 
bislang allerdings nicht die erf orderliche Entkopplung 
zwischen den verschiedenen Schichten. 

Zur Vermeidung der genannten Nachteile und unter Beibehal- 
tung der vorteilhaf ten und gewunschten Entkopplung der 
jeweiligen Schichten des Multi-Tier-Modells-, ist es wun- 
schenswert, dieses insofern weiter zu entwickeln, als dafi 
die mittlere Schicht liber gleichrangige Software Komponen- 
ten dezentral organisiert ist. 

Aufgabe der Erfindung ist es deshalb, eine Software Archi- 
tektur fur einen Appli kationsprozess zu schaffen, die die 
Vorteile des Mult i-Tier-Konzeptes und die des Micro Kernel- 
Prinzips vereint. 

Diese Aufgabe wird durch ein Verfahren der eingangs genann- 
te Art gelost, bei dem die zweite Schicht vorzugsweise 
zumindest einen Server umfalit und vollstandig als micro- 
kernel-basiertes Client /Server-System organisiert ist und bei 
dem zwischen der ersten und zweiten Schicht eine Schnittstel- 
le in Form einer Message festgelegt ist, wobei ein Serverauf- 
trag zumindest folgende Schritte umfalit: 

- der Client ubersetzt den Serverauf trag in eine Message mit 
den jeweiligen Argumenten, 

- der Client sendet die Message an den Server vorzugsweise 
aus der mittleren Schicht, 

- der Auftrag wird gegebenenf alls weitergeleitet und voll- 
standig abgearbeitet und 
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- das Ergebnis des Auftrages wird anhand der Message zuruck- 
gesendet . 

Weiterhin wird diese Aufgabe gelost durch ein 

Client /Server-System nach Anspruch 18, ein Compute rprogramm 
gemafl Anspruch 19, ein Computerprogrammprodukt gemafl An- 
spruch 20 und eine Vorrichtung nach Anspruch 21. 

Entsprechend der erf indungsgemaUen Struktur ist die zweite 
Schicht bzw. das Middle-Tier ausschlieMich fur ein Routing 
des Serverauf trages ausgelegt und benotigt kein client - 
spezifisches Wissen. 

Der Serverauf trag, der im allgemeinen in einer Anfrage (an 
eine Datenbank) und in einer Antwort (Ergebnis der Datenbank 
Query) besteht ist er f indungsgemali in eine "Frage- 
Transaktion" - ausgehend von dem Client an den Server - und 
in eine "Antwort-Transaktion" - ausgehend von dem Server an 
den Client - zerlegt. Diese sind physikalisch voneinander 
entkoppelt, so dass die Messages vollstandig asynchron zuein- 
ander gehalten werden. 

In einer bevorzugten Ausf uhrungsf orm der Erfindung gehort der 
Client der ersten Schicht und der Server der zweiten und/oder 
dritten Schicht an, 

Der Server liefert nach Abarbeitung des Auftrages ein Ergeb- 
nis des Auftrages an den aufrufenden Client oder eine andere 
Zieladresse. 

Dabei ist die Rucksendeadresse des Serverauf trages in der 
Message enthalten . 

Erf indungsgemali wird das Middle-Tier vollstandig im Micro 
Kernel realisiert. Die Server realisieren alle Dienstleistun- 
gen des Systems. 
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Die Message eines Clients aus der ersten Schicht wird stets 
unmittelbar an eine Wurzelkomponente des Micro Kernels der 
zweiten Schicht gesendet, der die Message dann an eine Verar- 
beitungskomponente weiterleitet - 

Bevorzugterweise umfafit der Micro Kernel der zweiten Schicht 
mehrere Subsysteme, die ihrereits in eine oder mehrere Kompo- 
nenten aufgeteilt sind. Dies fuhrt vorteilhaf terweise zu 
einem hohen Grad an Modularitat und macht das System insofern 
flexibel, da die Dienstleistung eines Servers auf mehrere 
Komponenten aufgeteilt werden kann, ohne daft der Verwaltungs- 
aufwand hinsichtlich der Adressen steigt. 

Ein wesentlicher Vorteil ist auch darin zu sehen, daft 
Dienstleistungen bzw. Dienstleisungsserver auch wahrend des 
Betriebs entfernt, verandert oder hinzugefugt werden konnen 
und daft alter Applikations-Code ohne Einschrankungen in das 
System eingebunden werden kann. 

Ein Vorteil liegt in der transparenten Inter Modul Kommunika- 
tion. Durch das er f indungsgemafte Festlegen einer Schnittstel- 
le, muft sich beispielsweise ein beteiligter Entwickler nicht 
urn die Kommunikation mit anderen Modulen kummern. Die einzige 
ubergreifende Plattform ist die Spezif ikation der Messages. 
Diese ist umgangssprachlich orientiert und verlangt kein 
zusatzliches Wissen. 

Ein wichtiger Punkt ist die Nutzung aller Vorteile der A- 
synchronitat bei der Kommunikation untereinander, ohne auf 
Callbacks zuruckgreif en zu miissen. Sie stellen einen fehler- 
trachtigen Bereich dar, der dann auch immer nur mit tiefem 
Wissen und komplizierten Entwicklungswerkzeugen bearbeitet 
werden kann. 

Bedingt durch die Asynchronitat der Messages, sind viele 
Message Passing Aktionen gleichzeitig moglich, urn die Reakti- 
vitat des Systems zu erhohen. Dies fuhrt aber zum gleichzei- 
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tigen Aufruf der Komponenten durch verschiedene Threads, 
Diese mussen im Normalfall synchronisiert werden. 
Da in den Komponenten der zweiten Schicht bzw. in den soge- 
nannten Business Logik Komponenten nur eine lesende Anfrage 
5 bei der Datenbank, der sogenannte Routing Datenbank, und das 
Umkopieren der Argumente durchgefuhrt wird, ist in diesem 
Fall keine Thread Synchronisierung notig. Es werden nur 
funktionslokale Daten verwendet, die zu einem Thread Kontext 
gehoren. Dies erlaubt in Windows-basierten Systemen den 
10 Einsatz von COM Objekten im Multi Threaded Apartement (MTA) . 



Durch das Festlegen des Message-Ziels schon im sendenden 
Dienstleistungsserver, ist keine weitere Stelle mehr invol- 
viert, was die Zielplanung anbetrifft. Es ist von jedem 
15 Server aus moglich eine Kommunikation zwischen zwei anderen 
Server auszulosen, da diese Inf ormationen mit der Message 
transparent durch das System kopiert werden. 

Durch das spate Routing wird die Verteilbarkeit und Skalier- 
20 barkeit der Multi Tier und Micro Kernel Ansatze verbessert. 
Es ist Administratoren ohne Kenntnisse des Innenlebens der 
Dienstleistungsserver jederzeit moglich, die Verteilung der 
Komponenten liber verschiedene Server zu verandern. 

25 Ein weiterer Vorteil des Message-Pf ades , liegt in dem poten- 
tiellen Einsatz identischer Befehle fur unterschiedliche 
Dienstleistungsserver oder mit unterschiedlichen Datenfel- 
dern . 

Mit der Zeit konnen neue Dienstleistungsserver hinzukommen. 
30 Diese konnen dann iiber die existierende Inf rastruktur alle 
Dienstleistungen der anderen Server nutzen, ohne dass die 
Entwickler im Detail die Sourcetexte kennen mussen. Mit 
Anwendung der existierenden Messages, passen sie die Neuerun- 
gen nahtlos ins Gesamtsystem ein. 



35 



Die verbindliche Interface Spezif ikation in Form einer 
Message ist in einer bevorzugten Ausf uhrungsf orm der Erfin- 
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dung vom Typ "String" und wird durch die Argumente der 
Funktionen der Interfaces weitergegeben. Eine Message wird 
immer ubergeben, in dem die entsprechenden Argumente der 
Funktion des aufgerufenen Interfaces vom Aufrufer versorgt 
werden. Dadurch ist aus der Sicht des Aufrufers das Message- 
Passing vollstandig durchgefiihrt und abgeschlossen. 
Der Inhalt der Messages ist Gegenstand der Spezif ikation der 
jeweiligen Applikation. Diese muss aber nicht nur den Inhalt 
des Befehls und des Datenfeldes festlegen, sondern auch deren 
Syntax beschreiben. In dieser Ausf uhrungsf orm hat die Message 
f olgende Struktur : 
"Katego- 

rie+Subsystem+Bef ehlsgruppe+Bef ehl+Zeitstempel+Steuerf eld+ 
Ursprung+Quellname+Zielname+Nutzdaten" 

Jeder String, getrennt durch das Pluszeichen, ist ein eigenes 
Argument der Interf ace-Funktionen . So ist gewahrleistet , dass 
sich die Stringmanipulationen zum Gewinnen der Inf ormationen 
auf ein Minimum reduzieren. 

Weitere Vorteile, Merkmale und alternative, nicht ein- 
schrankend zu verstehende Ausf uhrungsf ormen der Erfindung 
sind in der nachf olgenden, detaillierten Figurenbeschrei- 
bung zu finden, die in Zusammenhang mit der Zeichnung zu 
le'sen ist und in der: 

Fig. 1 eine schematische Darstellung einer bekannten Multi 

Tier Architektur aus dem Stand der Technik, 
Fig. 2 eine schematische Darstellung von verschiedenen 

Komponenten einer zweiten Schicht eines erf indungsge- 

maften Micro Kernels, . 
Fig. 3 eine schematische Darstellung einer erf indungsgemafien 

Organisation, 

Fig. 4 eine beispielhaf te Darstellung einer Frage- und 

Antwort-Transaktion eines Dienstleistungs-Server- 
Auftrages und 

Fig. 5 ein Ablauf Diagramm des erfindungsgemafien Verfahrens 
zeigen. 
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Figur 1 zeigt das grundlegende, aus dem Stand der Technik 
bekannte Mulit Tier Modell, das hier aus drei Schichten 
(auch Tiers genannt) besteht: einer ersten Prasentations- 
schicht 10, einer zweiten bzw. mittleren Schicht 12 und 
einer dritten Datenschicht 13. Die Aufrufe der ersten in 
die zweite Schicht erfolgen bei Microsof t-basierten Syste- 
men liber COM oder DCOM Schnittstellen . Die Ruckantworten 
erfolgen uber Return Values des jeweiligen COM oder DCOM 
Aufrufes. Die zweite Schicht 12 dient zur Generierung von 
Datenbank-Abf ragen, z.B. SQL Queries, und muB daher die 
Struktur der dritten Schicht kennen. Die dritte Schicht 13 
beinhaltet die Daten und ein Datenbank Management System. 
Nachteilig bei diesem Aufbau aus dem Stand der Technik ist, 
daft ein aktiver Teil eines Client-Prozesses, ein sogenann- 
ter Thread, solange blockiert bleibt, bis der Datenbank 
Zugriff abgeschlossen ist. Dies fuhrt zu langen Wartezeiten 
und zu verminderter Leistungsf ahigkeit des Gesamtsystems . 

Bei der er f indungsgemaflen Losung ist die Entkopplung der 
Prozesse zwischen den jeweiligen Tiers 10, 12, 13 ebenfalls 
beibehalten worden. Doch das Middle Tier bzw. die mittlere 
Schicht 12 ist anders - namlich nach einem Micro Kernel 
Prinzip - organisiert. Dafiir ist eine feste Schnitt stelle 
in Form einer Message 14 fur das Middle Tier 12 entwickelt 
worden. Weiterhin werden erf indungsgemaft (modulare) Kompo- 
nenten eingesetzt, die zumindest Teile einer Server- 
Di ens t lei stung realisieren . 

Unter Bezugnahme auf Figur 2 wird nachstehend die grundlegen- 
de erf indungsgemafte Struktur erlautert. Die Verbindung des 
Multi Tier Ansatzes und des Micro Kernel Prinzips nutzt einen 
kurzzeitigen Rollenwechsel (vom Empfanger zum Sender) zwi- 
schen Client C und Server S . Das Middle Tier 12 wird kom- 
plett im Micro Kernel realisiert, wobei die Satteliten darum 
herum sowohl aus der ersten Schicht 10 als auch aus der 
Datenschicht 13 stammen konnen und auch Subsysteme genannt 
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werden. Allgemein gesprochen realisieren sie alle Dienstleis- 
tungen . 

Wie in Figur .3 gezeigt, beruht der Micro Kernel auf strikter 
Client Server Architektur. Der Client C gibt einen Auftrag in 
Form einer Message 14 und beendet dann den Aufruf. Danach ist 
der Client C wieder frei und kann weitere Prozesse bearbei- 
ten . 

Der Auftrag wird vom ausgewahlten Subsystem bearbeitet, ohne 
dass das fragende Subsystem oder die mittlere Schicht 12 noch 
blockieren, da der Auftrag ja an das ausfuhrende Subsystem 
abgegeben wurde. Ist das angefragte Subsystem mit der Bear- 
beitung der Message 14 fertig, wird es nun seinerseits zum 
Frager bzw. Client C und ruft ein Zielsubsystem auf die genau 
gleiche Art und Weise auf (z.B. den ursprunglichen Frager), 
urn seine Ergebnisse ebenfalls iiber ein Message Passing abzu- 
senden. Damit ist ein Inf ormationsrundlauf beendet, der 
erfindungsgemali in zwei Transaktionen - einer Frage- 
Transaktion und eine Antwort-Transaktion - zerlegt ist. Eine 
Transkation ist bildlich als Stichleitung vorstellbar. 

^Die erf indungsgemafte Flexibility kommt daher, dass die 
Gesamtkommunikation aus diesen zwei Stichleitun- 
gen/Transaktionen besteht, der Frage-Transaktion und der 
Antwort-Transaktion. Zwischen beiden besteht nur eine logi- 
sche Kopplung. 

Die Antwort-Transkation gent tiblicherweise an den ursprungli- 
chen. Client Client C, der die Frage-Transaktion abgesetzt 
hat. Es ist jedoch auch mdglich, die Antwort-Transkation an 
eine andere Zieladresse zu senden. 

Das Routing wird vollstandig vom Micro Kernel durch die 
Business Logik erledigt, die konsequent durch Komponenten 
realisiert wird. Das Routing wird auf der Basis einer Daten- 
bank, der Routing Datenbank, durchgef iihrt . So ist sogar eine 
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Anpassung oder Erweiterung des Message Passing wahrend des 
Betriebs moglich. 

Eine Stichleitung/Transaktion muss bis zum deklarierten Ende 
bestehen bleiben. Durch die Zweiteilung in eine Fra- 
ge/Antworttransaktion entstehen zwei Transaktionen . Deren 
Blockadezeit hangt vorteilhaf terweise nicht von der angefrag- 
ten Dienstleistung ab, sondern nur von technischen Gegeben- 
heiten wie z.B. den Net zwerkverbindungen, der Anzahl der 
Rechner oder der Rechenleistung . 

In Figur 5 ist ein Flow Chart gezeigt, das den grundlegenden 
Ablauf des erf indungsgemaften Verfahrens erlautert: 
Dabei sind auf der linken Seite dieser Figur die Aktionen von 
Client C, einem Programmteil und dem Server S dargestellt, 
die die Frage-Transakt ion betreffen, wahrend auf der rechten 
Seite die Aktionen gezeigt sind, die die Antwort-Transaktion 
betref f en. 

Ein Client C benotigt nun bestimmte Daten ausder Daten- 
schicht 13 und generiert mit diesen aktuellen Argumenten eine 
Message 14. Diese Message betrifft zu diesem Zeitpunkt die 
Frage-Transaktion . Daraufhin schiebt der Client C die Message 
14 in die Sende-Queue des Client C, die nach dem FIFO (First- 
In-First-Out) Prinzip organisiert ist und kehrt zuruck. Der 
angesprochene Programmteil holt nun das oberste Element der 
Queue ab und leitet die Message 14 mit den codierten Routing 
Inf ormationen durch die zweite Schicht von Server S zu Server 
S bis in eine Empf angs-FIFO des Server S und- kehrt dann 
zuruck. Nun kann der Server S die Message 14 bzw. den Frage- 
Teil aus der Empf angs-Queue auslesen und diese bearbeiten. 
Damit ist der erste Abschnitt des erf indungsgemaBen Server- 
auftrages erledigt. Nun mufl das Ergebnis wieder an den ur- 
sprunglichen Client C oder eine andere Zieladresse zuruck 
gesendet werden. Hierzu generiert der Server S wiederum eine 
Message 14 nach dem gleichen Prinzip, die in diesem Fall die 
Antwort-Transaktion codiert und stellt sie in die Sende-FIFO 
des Server Server S, urn danach zuruck zu kehren. Nun kann der 
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Programmteil die Antwort-Transaktion aus der Sende-FIFO 
auslesen und anhand der Routing Inf ormationen bis zur Emp- 
fangs-FIFO des Client C innerhalb der zweiten Schicht 12 
weiter routen, um danach zuruck zu kehren. 

Der Client C holt die Message 14 nun aus der Empf angs-FIFO 
des Client C und erfafit den Zeitstempei, der die Message 14 
eineindeutig identif iziert . Uber den Zeitstempei im Millise- 
kunden Bereich karin er eindeutig die dazugehorige Frage- 
Transaktion bestimmen und sozusagen die zweiteilige Struktur 
(Frage-Antwort) in eine einteilige (Auftrag) zusammenset zen . 
Der gesamte Auftrag ist nun abgeschlossen . 

Die Kommunikation hinsichtlich der Aufrufe ist mit der Kompo- 
nententechnik realisiert. Hierbei ruft ein Komponenten Client 
einen Komponenten Server nur uber dessen offentliches Inter- 
face auf. Das Programm wird dann durch eine angehangte und 
abgekapselte Komponentenklasse realisiert. Der Begriff "Of- 
fentlichkeit" im Zusammenhang mit dem Interface bedeutet, 
dass es eine Definition erfahrt, die in jedem Rechner global 
einsehbar, es eineindeutig identif iziert und auch liber Rech- 
nergrenzen erfragbar ist. Erreicht wird dies durch Verwendung 
von GUIDs (Globally Unique Identifier) fur das Interface, die 
Komponentenklasse, Ressourcen und vieles mehr. 

Ein Interface bzw. die Schnittstelle stellt eine Sammlung von 
Funktionen mit Auf ruf parametern dar. Diese konnen grundsatz- 
lich jeden Typ annehmen. In der bevorzugten Ausf uhrungsf orm 
wird "String" als genereller Standardtyp verwendet. Damit 
steht ein generischer Typ zur Verfugung, der ein Message 
Passing fur alle nur denkbaren Entwicklungen erlaubt. Dies 
wird realisiert durch den Aufruf einer Komponente uber eine 
ihrer Funktionen, der dann bis zu seiner Beendigung bio- 
ckiert. Innerhalb dieser Funktion wird die mitgegebene Messa- 
ge umgewandelt und interpretiert . Erst nachdem dies geschehen. 
ist, gibt sie den Programmf luss wieder an den Aufrufer zu- 
ruck. 

Das Message Passing wird realisiert durch „textuelle Messa- 
ges" . Es wird durch denjenigen Textcode realisiert, der fur 
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die jeweilige Zielplattf orm nativ ist. Bei Windows und vielen 
UNIX Plattformen ist dies UNICODE. 

Eine Message setzt sich aus mehreren Bereichen zusaminen, die 
sich darin unterschelden, dass sie entweder als eigenes 
5 Argument auftauchen, oder zu einem String mit definiertem 
Trennzeichen wie folgt zusammengeset zt werden: 

"Kategorie . Subsystem. Bef ehlsgruppe . Bef ehl + Datenf eld" . 

10 Das Datenfeld setzt sich im allgemeinen aus den folgenden 
Stringbereichen zusammen : 
Quellname | Steuerf eld | Nutzdaten . 



Abkurzend wird folgendes vereinbart: Der "Katego- 
15 rie . Subsystem. Bef ehlsgruppe" Teil der Message wird Message 

Pfad genannt. Der Teil "Bef ehl + Datenfeld" bekommt den Namen 
Token, da er unverandert durch das System durchgereicht wird. 

Eine Message 14 setzt sich also immer aus Message Pfad und 

20 Token zusammen. 

Der Message Pfad realisiert eine Hierarchie, die eine relati- 
onale Beziehung festlegt, die das Routing eindeutig von der 
Wurzel bis zum Ziel ermoglicht. Wie bei relationalen Bezie- 
hungen iiblich, gilt die Eindeutigkeit nur von links nach 

25 rechts im Message Pfad bzw. oben nach unten. 

Der Message Pfad bezeichnet ein Ziel, das mit einem Subsystem 
identisch ist . An dieses wird der Token abgeliefert. 
Diese Hierarchie identif iziert die Schlussel einer Routing 
30 Datenbank. 

Der Schlussel Kategorie stellt die erste Ebene der Hierarchie 
dar. Ist er identif iziert , wird in der zweiten Ebene durch 
den Schlussel Subsystem eine weitere Verzweigung festgelegt. 
35 Die Bef ehlsgruppe verzweigt als dritte Ebene und ermoglicht 
die letzte Verzweigung, die durch den Befehl im Token selbst 
festgelegt wird. 
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So ergibt sich in Anlehnung an ein hierarchisches Filesystem 
eine Art Directory, das eine eindeutige Identif izierung eines 
Files erlaubt, das in dieser Analogie dem Token entspricht. 
Die eindeutig identif izierbaren Schlussel dienen zum Abspei- 
chern der jeweiligen Auf ruf inf ormationen der verschiedenen 
Komponenten der jeweils naehst tieferen Ebene. 

Der Vorteil des Hinzufugens eines Message Pfades liegt in dem 
potentiellen Einsatz gleicher Befehle fur unterschiedliche 
Subsysteme oder solche mit unterschiedlichen Datenf eldern . 
Der Message Pfad kann uber eine externe Datenbank realisiert 
werden . 

Jede Ebene wird durch eine Komponente im Middle Tier 12 oder 
Micro Kernel realisiert. Unter einem identif izierten Schlus- 
sel sind alle Inf ormationen abgelegt, die fur einen Aufruf 
einer Software Komponente notig sind. Fur jeden Schlussel 
gibt es eine Komponente. Die Gesamtheit dieser Routing Kompo- 
nenten stellt die Business Logik im Micro Kernel oder Middle 
Tier 12 dar. Diese Komponenten mussen nur einmal entwickelt 
werden. Es bieten sich mehrere Tools dazu an. Im Fall von MS 
Com gibt es Visual Basic oder Visual C++ und ATL . 

Da parallel mehrere Stichleitungen betrieben werden, konnen 
einige Routing Komponenten potentiell in verschiedenen 
Threads gleichzeitig aufgerufen werden. Dies ist ein klassi- 
scher Fall fur eine Threadsynchronisierung . Im Falle der 
erf indungsgemaften Architektur entfallt sie komplett, indem 
zum einen lokal erzeugte Daten und Ressourcen genutzt und 
globale Daten nur gelesen werden. In C++ waren dies die 
automatischen Variablen und die Klassenattribute . 
Dies hat die Folge, dass bei MS Com der Multi Threaded Appar- 
tement (MTA) Typ verwendet wird. Hierbei liegt es in der 
Verantwortung der Komponente, ob sie ihre Attribute (kompo- 
nenten-globale Daten) synchronisiert, da jeder Thread auf 
jeden Fall in die Komponente eintritt. Im Falle dieser Archi- 
tektur werden sie maximal lesend verwendet, also wird der 
eintretende Thread nirgends blockiert. Dies fuhrt zu einer 
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optimalen Granularitat , die bis in die Threadwechselzeiten 
hinabreicht . 

Urn die Arbeit von Object Request Broker wie MTS/Com+ oder 
CORBA nutzen zu konnen, mussen die Komponenten des Micro 
Kernel sich der „Just In Time Aktivierung" dieser Broker 
bewusst sein. Dies hat zur Folge, dass die oben erwahnten 
automatischen Variablen oder Ressourcen besonders erzeugt und 
freigegeben werden mussen. Dies unterscheidet sich grundsatz- 
lich vom Konstruktor/Destruktor Ansatz des Klassenkonzepts . 



Falls neue Routen hinzugefiigt werden sollen, ist kein Pro- 
grammtext zu andern, da erst zur Laufzeit der Komponenten die 
Aufrufe uber die Routing DB aufgelost werden. Dies setzt eine 
gelungene Absprache zwischen den Subsystemen voraus, da der 
15 Token ganz konkrete Daten enthalt, durch die Fehler ausgelost 
werden konnen. Aber auch hier kann die Middle Tier 12 mithel- 
fen, Fehler zu visualisieren . Da die ganze Message 14 aus dem 
Datentyp Text besteht, ist sie zu jedem Zeitpunkt und in 
jeder Ebene im Klartext, also unverschlusselt , zu kontrollie- 
20 ren. Belegt man z.B. das Datenfeld eines Tokens, der eine 

Anfrage an eine Datenbank per "Select" durchfiihren soil, mit 
dem kompletten Select String, so ist dieser aktuell erzeugte 
dadurch im Klartext einzusehen. 



^25 Neue Befehle werden hinzu gefugt, indem ein neuer Eintrag in 
der Routing Datenbank vorgenommen wird. Die Re.alisierung 
findet dann komplett in den beiden Subsystemen statt, die 
uber die Messages 14 miteinander reden wollen. 

30 Im folgenden soil im Zusammenhang mit Figur 4 beispielhaft 

gezeigt werden, wie das Message Passing bei der erf indungsge- 
maBen Architektur durchgefiihrt wird. 

Der Startpunkt ist ein fragendes Subsystem Grafik, das eine 
35 Maske realisieren soil. Diese Maske erfragt alle Informatio- 
nen, die zur Darstellung einer gewissen Treffermenge notwen- 
dig sind. Das Subsystem Grafik nutzt sie um einen SQL Select 
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String fur das Datenfeld zu erzeugen und verbindet ihn mit 

einem zuvor spezif izierten Befehl zu einem Token 

"Get. Graf ik.O. SELECT wobei "Grafik" der Name des sen- 

denden Subsystems und „0" der Inhalt des Steuerfeldes ist. 

Urn den Token zum richtigen Ziel fuhren zu konnen wird nun der 

Message Pfad festgelegt: "Beispiel . Visual . Holen" . Auch dieser 

ist Gegenstand der vorausgehenden Spezif ikationen . Diese sind 

unabhangig von der hier beschriebenen Architektur. 

Der komplette Aufruf lautet also 

"Beispiel . Visual . Holen . Get . Grafik . 0 . SELECT 

Mit diesen Strings wird eine Wurzel Komponente des Micro 

Kernel aufgerufen. Dies ist die Standard Interprozesskommuni- 

kation, die bei alien Obergangen zwischen den Schichten bzw. 

von einem Subsystem zum Micro Kernel immer gleich ist. Es 

wird immer dieselbe Wurzel Komponente aufgerufen, die immer 

der Standard Einsprungpunkt einer Aufruf kette oder Stichlei-. 

tung ist, wie sie im folgenden beschrieben wird. Auch ist sie 

die sogenannte Transaktionswurzel, d.h. hier fangt die Trans- 

aktion an. 

Ihre erste Aktion besteht im Interpretieren des Message 
Pfades. Hier dient die Kategorie "Beispiel" als Schlussel, urn 
aus der Routing Datenbank die Aufruf inf ormationen fur die 
nachst tiefere Komponente erfragen zu konnen. Diese wird dann 
auph sofort aufgerufen, wobei der Message Pfad und der Token 
^einfach durchgereicht werden. 
Diese Komponente der Ebene Kategorie arbeitet nach demselben 
Prinzip wie die Wurzel Komponente: Interpretation des Message 
Pfades („Visual"), Heraussuchen des Schlussels aus der Rou- 
ting Datenbank und Gewinnen der Aufruf inf ormationen . Das 
Ergebnis ist der Aufruf einer Komponente, aus der urn eins 
tiefer gelegenen Ebene namens Subsystem. 

Diese Komponente arbeitet nun wiederum nach dem selben Prin- 
zip und ruft seinerseits eine Komponente „Holen >x aus der 
Ebene Bef ehlsgruppe auf. 

Insgesamt .wird eine Auftrag in rekursive Aufrufe an die 
jeweiligen Server S umgesetzt. Jede Ebene kann beliebig viele 
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Komponenten enthalten. Deshalb ist der Aufrufpfad auch nur 
von oben nach unten eindeutig und nicht umgekehrt. 
Die Ebene Bef ehlsgruppe ist die direkte Auf ruf schicht der 
Subsysteme. Sie enthalt die Clients C der Subsysteme und ist 
5 die Grenze des Middle Tier (oder Micro Kernel) 12 zu einem 
Subsystem. 

In diesen Komponenten, im Gegensatz zu den obigen, wird der 
Befehl nicht mehr weiter interpretiert . Der Token im Beispiel 
„Get . Graf ik. 0 . SELECT . : wird so an das Subsystem weiterge- 

10 geben. Der Message Pfad muss deshalb sicherstellen, dass 

mehrere, gleichartige Befehle von dem selben Subsystem abge- 
arbeitet werden. Diese letzte Komponente des Micro Kernel 

).* weifl implizit, oder holt explizit die Information (GUID) , wie 
das spezielle Subsystem aufgerufen werden muss. Dies bedeu- 

15 tet, dass es sinnvoll ist fur jedes Subsystem nur eine kor- 
respondierende Komponente in der Ebene Bef ehlsgruppe zu 
implementieren, da sie sich dann nicht mit einer Anfrage bei 
der Routing Datenbank beschaftigen muss. In diesem Fall ist 
implizites Wissen notig, da im Token selbst keine Information 

20 uber das Ziel Subsystem enthalten ist. Diese steckt alleine 
im Message Pfad. Deshalb ist bei der Implementierung einer 
neuen Message in der mittleren Schicht 12 kein Code und in 
den Subsystemen der ganze Code zu implementieren. 
Der Befehl „Get . Graf ik. 0 . SELECT . . mit seinem Select String 

25 im Datenfeld wird nun an das entsprechende Subsystem Data 

^* weitergereicht . Falls es das falsche Subsystem sein sollte, 

so liegt der Fehler im Message Pfad, der das Routing leistet. 
Das Senden an das Subsystem lauft wieder liber einen Komponen- 
ten Auf ruf ab. Aus der Komponente der Ebene Bef ehlsgruppe 

30 wird das Subsystem als Server aufgerufen. 

Dazu muss das Subsystem eine Komponente mit Interface sein. 
Urn eine Entkopplung zum Middle Tier 12 herzustellen, dient 
die Komponenten Klasse, die uber das Interface direkt aufge- 
rufen wird. Sie dient nur dazu, die empfangenen Inf ormationen 

35 in eine Queue abzulegen und dem restlichen Subsystem seine 
Ankunft zu signalisieren . 
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Das restliche Subsystem lauft in mindestens einem Worker 
Thread, urn einen eigenen Ausf uhrungspf ad zu besitzen. 
Dadurch kann die Komponenten Klasse sofort terminieren und 
die Transaktion damit erfolgreich beenden. 
5 Einmal im Subsystem Data angekommen, ist die Stichleitung 

oder Transaktion abgeschlossen und die beteiligten Komponen- 
ten terminieren auch erfolgreich. 

Da dies nur die halbe Aktion fur die Abarbeitung des Auftra- 
10 ges ist, muss nun eine Antwort wieder zuriick geroutet werden. 
Dies geschieht nun auf die exakt gleiche Weise wie die Frage 
abgelief ert wurde . 

An dieser Stelle kommt das Micro Kernel Prinzip zur Anwen- 
dung. Im Gegensatz zum Multi Tier Modell kann hier jedes 

15 Subsystem zum Top Level werden und per Message Passing einen 
Befehl an den Bottom Level schicken. In dem vorstehend unter 
Bezugnahme auf Figur 4 beschriebene. Beispiel ist es das 
ehemals fragende Subsystem Grafik. Die Frage ging von Grafik 
nach Data uber eine Transaktion und die Antwort soli nun von 

20 Data nach Grafik geschickt werden. Ist diese zweite Transak- 
tion ebenfalls beendet, so sollte im Subsystem Grafik der 
Recordset der Ergebnismenge angekommen sein urn visualisiert 
^zu werden. Dabei wurde nirgends eine Festlegung notwendig, 
/ dass das Quellsubsystem auch wieder das endgultige Zielsystem 

25 sein muss. Vielmehr muss es als bef ehlsinharente Information 
bei Implementierung dieses Befehles abgesprochen und spezifi- 
ziert worden sein. Als allgemeingultige Zusatzinf ormation 
steht im Frage Token die Quelle zur Verfugung. Daraus kann 
eine Bedingung abgeleitet werden, ob wieder zuriick geroutet 

30 werden soli, oder ein neues Ziel notig wird. Daraus ist zu 

erkennen, dass die Befehle genau die Stelle in dieser Archi- 
tektur sind, wo die Applikationsspezif ika adressiert werden. 
Deshalb ist es sinnvoll, fur den Einsatz von Debugging oder 
Case Tools, unter den Bef ehlsschlusseln auch eine Spezifika- 

35 tion mit abzulegen. Da der Datentyp String verwendet wird, 
fallt. es. sehr leicht auch diese Information beim Aufruf der 
Routing Datenbank weiterzuleiten . 
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Da die Zeit, in der die Stichleitung existiert, im uberwie- 
gendem Matte von der Zugrif f sgeschwindigkeit auf die Routing 
Datenbank abhangt, ist- hier ein weites Feld fur Design Ent- 
scheidungen. Bei nicht so kostspieligen Systemen, kann man 
5 z.B. einfache Files verwenden oder bei Windows 2000 die 
InMemoryDataBase des Com+ Systems einsetzen. Geht es um 
komplexe Bef ehlsstrukturen auf High Performance Systemen, so 
kann auch eine Oracle DB eingesetzt werden. 

Auf jeden Fall ist es von Bedeutung, dass der gesamte Ablauf 
10 der Inf ormationsbeschaf f ung durch das Middle Tier 12 streng 
zweigeteilt ist. Es sind dann zwar auch zwei Transaktionen 
beteiligt, aber keine von beiden ist in ihrer Blockadedauer 
vom bef ehls-spezif ischen Problem abhangig. Diese Zeit liegt 
komplett zwischen den beiden Transaktionen und garantiert 
15 somit die Asynchronitat zwischen Frage und Antwort. Dies 

verlagert die Aufgabe der Synchronisierung der beiden Trans- 
aktionen komplett in die Subsysteme. Nur hier konnen zum 
Beispiel gegenseitige Uberholungen von Antworten wieder 
bereinigt werden. 
20 Dies ist sehr giinstig fur die Forderung nach hoher Skalier- 

barkeit. Durch viele, kleine und determinierte Blockadezeiten 
ist i. a. eine viel bessere Skalierung moglich, als durch die 
wenigen und lang anhaltenden, die bei dem bekannte Multi Tier 
Modell aus dem Stand der Technik auftreten. Dazu kommt noch 
^^25 die Tatsache, dass die unterschiedlichen Leistungsanf orderun- 
/ gen immer mit ein und derselben Software erfullt werden, da 

ja die Architektur unverandert bleibt und nur die Rechenleis- 
tung durch den Einsatz einer hoheren Anzahl von Rechnern 
erhoht wird. 

30 

Vorteilhaf terweise ist eine Verteilung auf verschiedene 
Rechner von Teilen des Gesamtsystems bis herunter zu den 
Komponenten moglich. 

35 Die Frage/Antwort-Transkationen mussen jedoch nicht notwendi- 
gerweise, wie hier im Beispiel geschildert, zeitlich nachein- 
ander ablauf en. In jedem Moment kann jedes Subsystem von 
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jedem anderen Dienste anfordern. Genau hier hat diese Archi- 
tektur ihre Starken. Durch die Zweiteilung der Transkationen, 
werden innerhalb einer Transaktion keine Daten gesperrt. Dies 
geschieht komplett in der Zeit dazwischen und nur im dienst- 
5 leistenden Subsystem und nicht im Micro Kernel. Die Frage der 
Sicherung muss auf einer hoheren Protokoll Ebene zwischen den 
Subsystemen ausgehandelt werden. Dazu sind spezielle Messages 
vorstellbar, die z.B. einen Drei Wege Handshake realisieren. 
Da aber keine Daten gegen andere Aufrufe geschiitzt werden 
10 mussen, darf jede Komponente mehrere Instanzen gleichzeitig 
aktiv halten. 

1st, unter der Annahme eines linearen Anwachsens des Ressour- 
cenverbrauchs mit der Anzahl der Messages, ein Engpass zu 
15 erwarten, so ist ein Objekt Broker wie MTS , COM+ oder CORBA 
einzusetzen. Sie reduzieren diese lineare Abhangigkeit mit 
der Hilfe von Just In Time Aktivierung, Objekt Pooling, 
Thread Pools und Load Balancing. 

20 Da der wichtigste Teil, die Kommunikation zwischen den Sub- 
systemen, mit dem Message Passing unverandert bleibt, bleibt 
es fur die Komponenten transparent, ob sie eine Dienstleis- 
tung im selben Rechner erfragen, oder uber Rechnergrenzen 
hinaus (Bsp. : COM/DCOM) . Der gleichzeitig verwendete Micro 

25 .Kernel erlaubt diesen skalierenden Ansatz sogar bis ins 

./ Subsystem hinein. Da alle Features hier implementiert werden, 
sind auch hier Performance Verbesserungen uber den Ansatz der 
Verteilung auf mehrere Rechner zu erreichen. Neue Features, 
die meistens mit hoherer Rechenzeitanf orderungen einhergehen, 

30 sind so ohne Neukompilierung anfugbar. 

Eine Forderung nach leichter Anpassbarkeit ist durch das 
Herausfiihren der spezifischen Befehle in die Routing Daten- 
bank erfullt. Die unterschiedlichen Anf orderungsprof ile 
werden durch die jeweilige Anpassung der Routing Datenbank 

35 realisiert. Es ist auch vorstellbar ein eigenes Tool zu 
entwickeln, das die abstrakte Information in der Routing 
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Datenbank visualisiert . Somit sind Erweiterungen und Wartun- 
gen am System ohne Programmierkenntnisse moglich. 

Da nur Komponenten als tragende Software Elemente verwendet 
5 werden, und alle spezifischen Dinge wie Features und Algo- 
rithmen in den Subsystemen konzentriert vorliegen, ist eine 
evolutionare Weiterentwicklung einfach moglich, Im jeweiligen 
Subsystem liegen alle Software Module vor, die mit dem jewei- 
ligen Problemkreis zu tun haben. Also kann immer der alte 
10 Code weiterverwendet werden, indem er vom neuen innerhalb des 
Subsystems einfach direkt aufgerufen wird. Anschlieftend wird 
das neue Subsystem ins System eingefugt, das ja wegen der 




Beibehaltung der Architektur von den Anderungen nichts be- 



merkt . 

15 Eine weitere Variante, alten Code weiter zu verwenden ist, 
dass komplette Applikationen von einer Komponenten Hiille 
umgeben werden, die fur alle Daten Anpassungen sorgt, die 
diese Applikation erwartet. Durch dieses Vorgehen ist sicher- 
gestellt, dass die alte Applikation nach auften eine Komponen- 

20 te darstellt und nach innen immer noch arbeitet, als ob sie 
direkt vom Betriebssystem aufgerufen werden wurde . Wenn man 
nun diese Komponente mit dem Standard Interface der Architek- 
tur fur Subsysteme versieht, kann sie als solche auch stan- 
dardmaftig eingebunden werden. Dadurch erhalt die alte Appli- 
_25 kation alle Messages von den anderen Subsystemen, auch wenn 
' diese viel spater und deshalb optimaler abgestimmt entwickelt 

wurden. Aufgrund des Micro Kernel ist auch keine Positionie- 
rung dieser alten Applikation in der starren Multi Tier 
Struktur notig. 

30 Auf diese Art und Weise konnte der NetManager vor der Version 
5.X nachtraglich eine mittlere Schicht bekommen, die er als 
Objekt Broker (MTS,COM+) nutzen kann. 

Aufgrund der Verwendung von Komponenten ist ein Patching 
35 leicht durchf uhrbar . Ist eine Komponente als fehlerhaft 

erkannt, so wird sie als einziges Objekt verandert und neu 
compiliert. Der entscheidende Punkt ist, dass man darauf 
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achtet die eineindeutigen Charakteristika einer Komponente, 
ihre GUIDs, dabei nicht zu andern. Wieder eingefugt wird sie 
durch einfaches Uberschreiben des Zugrif f pf ades in der Kompo- 
nentenverwaltung ( bei Windows in der Registry) oder durch 
Uberschreiben der Komponente auf der Festplatte. Falls es 
sichergestellt ist, dass sie in diesem Moment nicht aufgeru- 
fen wird, kann dies auch im laufenden Betrieb geschehen. 

In der erfindungsgemali realisierten mittleren Schicht 12 
werden die Argumente der Funktionen nur kopiert oder dazu 
verwendet Routing Inf ormationen abzuleiten. Die empfangende 
Funktion kann mit einem C Pseudo Code wie folgt dargestellt 
werden: 

BSTR Ccomponente: rbstrPassing ( BSTR Kategorie, 

BSTR Subsystem, 
BSTR Befehlsgruppe, 
BSTR Befehl, 
BSTR Zeitstempel, 
BSTR Steuerfeld, 
BSTR Ursprung, 
BSTR Quellname, 
BSTR Zielname, 
BSTR Nutzdaten ) 

{ 



return bstrErgebnis ; 

} 

, wobei BSTR ein MS COM spezifischer Datentyp ist, der einen 
String bestimmter Lange darstellt. 

Es sei betont, dass die Beschreibung der fur die Erfindung 
relevanten Komponenten des Netzes grundsat zlich nicht ein- 
schrankend zu verstehen ist. Fur einen einschlagigen Fachmann 
ist insbesondere of f ensichtlich, dass die verwendeten Begrif- 
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fe funktional und nicht physikalisch zu verstehen sind. Somit 
konnen die Komponenten auch teilweise oder vollstandig in 
Software und/oder uber mehrere physikalische Einrichtungen 
verteilt realisiert werden. 
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Patentanspriiche 



1- Verfahren zur Steuerung eines Applikationsprozesses in 
einem verteilten System mit mindestens einem Client (C)und 
mindestens einem Server (S) , bei dem das System nach einem 
Multi-Tier-Modell organisiert ist und zumindest eine erste 
Prasentationsschicht (10), eine zweite Schicht (12) und eine 
dritte Datenschicht (13) umfaftt, 
dadurch gekennzeichnet , daft 

die zweite Schicht (12) vollstandig als micro-kernel- 
basiertes Client /Server-System organisiert ist und dass 
zwischen der ersten und zweiten Schicht (10, 12) eine 
Schnittstelle in Form einer Message (14) festgelegt ist, 
wobei ein Serverauf trag zumindest folgende Schritte umfaftt: 

- der Client (C) ubersetzt den Serverauf trag in eine Message 
(14) mit den jeweiligen Argumenten, 

- der Client (C) sendet die Message (14) an den Server (S) , 

- der Auftrag wird gegebenenf alls weitergeleitet und voll- 
standig abgearbeitet und 

- das Ergebnis des Auftrages wird anhand der Message (14) 
zuruckgesendet . 

2. Verfahren nach Anspruch 1, 
dadurch gekennzeichnet, daft 

die zweite Schicht (12) und/oder dessen Komponenten aus- 
schlieftlich fur ein Routing des Serverautrages ausgelegt ist. 

3. Verfahren nach mindestens einem der Anspruche 1 oder 2, 
dadurch gekennzeichnet, daft 

der Serverauftrag in eine "Frage-Transaktion" - ausgehend von 
dem Client (C) an den Server (S) - und in eine "Antwort- 
Transaktion" - ausgehend von dem Server (S) an den Client (C) 

- zerlegt ist, die physikalisch entkoppelt sind. 
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4. Verfahren nach mindestens einem der vorstehenden Anspru- 
che, 

dadurch gekennzeichne t , daft 

der Client (C) der ersten Schicht (10) und der Server (S) der 
5 zweiten und/oder dritten Schicht (12, 13) angehort. 

5. Verfahren nach mindestens einem der vorstehenden Anspru- 
che, 

dadurch gekennzeichne t , daft 
10 der Server (S) nach Abarbeitung des Auftrages ein Ergebnis 

des Auftrages an den aufrufenden Client (C) oder eine andere 
, Zieladresse sendet. 

-6. Verfahren nach mindestens einem der vorstehenden Anspru- 
15 che, 

dadurch gekennzeichnet , daft 

a lie Adressen und/oder Rucksendeadressen fur den Serverauf- 
trag in der Message (14) - vorzugsweise dynamisch - codiert 
sind. 

20 

7. Verfahren nach mindestens einem der vorstehenden Ansprii- 
che, 

dadurch gekennzeichnet, daft 

der Micro Kernel Subsysteme umfasst, die der zweiten Schicht 
j^25 (12) und/oder der dritten Schicht (13) angehoren. 

8 . Verfahren nach mindestens einem der vorstehenden Anspru- 
che, 

dadurch gekennzeichnet, daft 
30 ein Serverauf trag weitere, vorzugsweise ineinander geschach- 
telte Serverauf trage umfassen kann. 

9. Verfahren nach mindestens einem der vorstehenden Anspru- 
che, 

35 dadurch gekennzeichnet, daft 

die Rucksendung des Ergebnisses des Auftrags anhand von in 
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der Message (14) enthaltenen Routing-Inf ormationen vorzugs- 
weise bis zum aufrufenden Client (C) erfolgt. 

10. Verfahren nach mindestens einem der vorstehenden Anspru- 
che, 

dadurch gekennzeichnet, daft 

die Message (14) zumindest folgende Argumente umfaftt: 

- Ursprung, in dem die Adresse des aufrufenden Clients (C) , 

- Quellname, in dem die Adresse des auf zuruf enden Servers (S) 
und 

- Zielname, in dem die Rucksendeadresse fur das Ergebnis 
codiert ist. 

11. Verfahren nach Anspruch 10, 
dadurch gekennzeichnet, daft 

daft Ursprung und Zielname ubereinstimmen oder unterschiedlich 
sind. 

12. Verfahren nach mindestens einem der vorstehenden Anspru- 
che, 

dadurch gekennzeichnet, daft 

die Message (14) eines Clients (C) aus der ersten Schicht 
(10) stets unmittelbar an eine Wurzelkomponente des Micro 
Kernels der zweiten Schicht (12) gesendet wird, der die 
Message (14) dann an eine Verarbeitungskomponente weiterlei- 
tet . 

13. Verfahren nach mindestens einem der vorstehenden Ansprii- 
che, 

dadurch gekennzeichnet, daft 

die Verarbeitung in der zweiten Schicht (12) asynchron zu der 
Verarbeitung in der ersten und/oder dritten Schicht (12, 13) 
erfolgt . 

14. Verfahren nach mindestens einem der vorstehenden Ansprii- 
che, 

dadurch gekennzeichnet, daft 
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daft ausschlieftiich ein Teil des Clients (C) , der mit der 
zweiten Schicht (12) kommuniziert , fur die Zeit zwischen dem 
Serveraufruf und der Absendung der Message (14) bzw. einem 
Empfang einer Bestatigung blockiert ist. 

5 

15. Verfahren nach mindestens einem der vorstehenden Anspru- 
che, 

dadurch gekennzeichnet, daft 

daft mehrere Aufrufe gegebenenf alls mehrerer Clients (C) in 
10 einer Queue gespeichert werden, die vorzugsweise nach dem 
FIFO-Prinzip arbeitet . 

\4^-^ J 16. Verfahren nach mindestens einem der vorstehenden Ansprii- 
che, 

15 dadurch gekennzeichnet, daft 

der Micro Kernel der zweiten Schicht (12) mehrere Subsysteme 
umfaftt, die ihrerseits in eine oder mehrere Komponenten 
aufgeteilt sind. 

20 17. Verfahren nach mindestens einem der vorstehenden Anspru- 
che, 

dadurch gekennzeichnet, daft 

der Server (S) , vorzugsweise alle Server (S) der zweiten 
Schicht (12), keine auf tragsbezogenen Adressinf ormationen 
.25 verwalten muft/mussen. 

18. Client/Server-System zur Steuerung und/oder Realisierung 
eines Applikationsprozesses, das rechner-architektonisch so 
ausgelegt ist, daft es nach dem Verfahren nach zumindest einem 

30 der Anspruche 1 bis 17 arbeitet. 

19. Computerprogramm, das Instruktionen aufweist, die zur 
Ausfuhrung des Verfahrens nach einem der Anspruche 1 bis 17 
eingerichtet sind. 

35 



20. Computerprogrammprodukt , das ein computerlesbares Medium 
mit Computerprogramm-Code-Mitteln aufweist, bei dem nach 
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Laden des Computerprogramms der Computer durch das Programm 
zur Durchfuhrung des Verfahrens nach einem der Anspruche 1 
bis 17 veranlafit wird. 

5 21. Vorrichtung zur Durchfuhrung und/oder Organisation eines 
Applikationsprozesses in einem verteilten System, bestehend 
aus mindestens einem Client (C) und mindestens einem Server 
(S) , bei dem das System nach einem Multi-Tier-Modell organi- 
siert ist und zumindest eine erste Prasentationsschicht (10) , 
10 eine zweite Schicht (12) und eine dritte Datenschicht (13) 
umfafit, 

dadurch gekennzeichnet , daft 

die zweite Schicht (12) vollstandig als micro-kernel- 
basiertes Client/Server-System organisiert ist und dass 
15 zwischen der ersten und zweiten Schicht (10, 12) eine 

Schnittstelle in Form einer Message (14) angeordnet ist, 
wobei 

die Vorrichtung zur Abarbeitung eines Serverauf trag zumindest 
folgendes umfaflt: 
20 - ein Message-Generierungs-Modul , das zur Umsetzung des 

Serverauf trags in eine Message (14) mit den jeweiligen Argu- 
menten ausgelegt ist, 

- ein Sende-Modul, das zum Senden der Message (14) an den 
y Server (S) bestimmt ist, 

25 - eine Verarbeitungs-Einheit , die den Auftrag gegebenenf alls 
weiterleitet und vollstandig abarbeitet und 

- ein Rucksende-Modul, das das Ergebnis des Auftrages anhand 
der Message (14) zuriick sendet. 

30 22. Vorrichtung nach Anspruch 21, 
dadurch gekennzeichnet, daft 

die Vorrichtung eine Rechnerarchitektur aufweist, die zur 
Ausfuhrung des Verfahrens nach zumindest einem der Anspruche 
1 bis 17 ausgelegt ist. 



35 
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Zusammenf as sung 

Rechner- und/oder Sof tware-Architektur unter Verwendung von 
Micro-Kernel- und Multi-Tier-Konzept mit Komponententechnik 

5 

Die Erfindung betrifft ein Verfahren und ein System fur eine 
Rechnerarchitektur bei verteilten Client/Server-Systemen, bei 
dem das System nach einem Multi-Tier-Modell organisiert ist 
und zumindest eine erste Prasentationsschicht (10), eine 

10 zweite Schicht (12) und eine dritte Datenschicht (13) umfadt. 
Die zweite Schicht (12) ist vollstandig als micro-kernel- 
basiertes Client /Server-System organisiert. Zwischen der 
\^P^ ersten und zweiten Schicht (10, 12) ist eine Schnittstelle in 
Form einer Message (14) festgelegt, wobei ein Serverauf trag 

15 zumindest folgende Schritte umfafit: 

- der Client (C) generiert eine Message (14) und sendet die 
Message (14) an den Server (S) . Falls notwendig, wird der 
Auftrag weitergeleitet und vollstandig abgearbeitet . Das 
Ergebnis des Auftrages wird anhand der Message (14) zuriick 

20 gesendet. 
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FIG 5 



CLIENT generiert 
Message mit aktueller 
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SERVER generiert 
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Antwort-Transkation 



CLIENT leitet Frage- 
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